With advances in computing, networking and software technology, an increasing number of applications are implemented in distributed environments, often composed of multitier compute infrastructures. For example, many Internet applications are implemented on a compute infrastructure that can be divided into three tiers: network, compute, and application. One advantage of a multitier compute infrastructure is that different tiers can function at different “levels” while still interoperating with each other. In the three-tier example, the network tier operates at the “lowest” level of the infrastructure, the compute tier operates on top of that, and the application tier operates at the “highest” level. As a result, enterprise and other applications can be distributed among the tiers in a fashion that results in greater optimization and utilization of the infrastructure. For example, if a certain functionality is desired, it is not required that the functionality be implemented in a monolithic piece of software installed on a particular computer in a specific location within the network. Rather, the overall functionality can be distributed among different components within the multitier compute infrastructure.
Software component architectures such as Java 2, Enterprise Edition (J2EE™) and .NET are one approach which takes advantage of this flexibility. (J2EE is a trademark of Sun Microsystems, Inc.) Software functionality is divided among different software components, each of which can run on a different host located at a different network address. Each of the software components, computers and the network topology may be optimized for efficiency, security, scalability, or other factors. For example, in the monolithic approach, a single code base and a single computer may be called upon to handle user requests for enhanced images, retrieve raw images from a large image warehouse, and perform complex calculations to enhance the images. With the component approach, one software component and server could handle user requests, another retrieve images, and a third could perform the calculation. The overall enterprise is also more salable since incremental capacity can be added by adding more instances of software components or servers.
One drawback of the multitier and software component approaches is that, typically, many components are used in order to implement the desired functionality. For example, the software portion can be implemented by a large number of software components, each possibly executing on a different server, with the multiple servers located on different networks. Software components may not even be executing on the same server each time. The real-time execution load can be load balanced among a server farm, for example. Currently, it is not uncommon for an enterprise application to have thousands of components, many of which must work simultaneously with each other in order for the overall enterprise application to function properly. In addition, multiple relationships between components exist within each tier, as well as across tiers of the compute infrastructure. For example, in the application tier, a web server and application server might work together to handle user requests. Cross-tier relationships can be more complex, such as those linking the web server, DNS server and access router with each other, but these often are the relationships that have a direct bearing on the availability, performance and security of the overall application.
Due to this increased complexity, managing a multitier compute infrastructure is more difficult. Typical management tools are mostly limited to a single tier. Many of these tools were developed for system administrators who are responsible only for a single tier. That is, one system administrator is responsible for networking, another for computers, and another for software loaded on the computers. Single-tier tools can give some visibility into the tier for which the system administrator is responsible, but do not give visibility into cross-tier relationships or interactions.
Single-tier tools also do not give direct visibility into the service which is a business' end goal. For example, in the image enhancement example, the business is really interested in the delivery of enhanced images, not in the congestion level of its internal routers or the state of its internal network. The router and network are of interest only to the extent that they impact the business service of delivering enhanced images but, with single-tier tools, it is difficult, if not impossible, to determine this relationship. As a result, the relationship typically must be manually pieced together, one tier at a time, and often using knowledge that resides only in some key employee's head. This is both time-consuming and risky—for example, if the key employee were to be unavailable.
Additionally, a lack of knowledge or incorrect knowledge about a cross-tier relationship can make the business impact of an outage unknown. For example, if an application server requires an upgrade to fix a potential security problem, the complexity of the cross-tier relationship may make it difficult to know which businesses processes could be directly or indirectly affected by the application server downtime. Similarly, the scope of the potential security problem could be unknown as well.
Other approaches attempt to address these shortcomings, yet lack visibility into enterprise-wide performance management analytics or business metrics. Much effort is being spent on approaches based on monitoring. OPENVIEW™ and TIVOLI® are examples of efforts in this general direction. (OPENVIEW is a trademark of Hewlett-Packard Company and TIVOLI is a registered trademark of International Business Machines Corp.) Management tools can monitor individual components in the infrastructure through instrumentation with increasing detail and sophistication. This can give improved visibility into the individual component but does not effectively address cross-tier visibility or the relationship between a component and a business service. For example, processor throughput, server availability and similar metrics at best can only give indirect visibility into business services, for example whether customers have access to an enterprise application and can perform promised tasks at published service levels.
What is therefore needed is a logical grouping of distributed components that: (1) provides visibility of cross-tier interactions; (2) provides metrics or performance analysis of a business process; and (3) provides a grouping of logical applications or sub-parts of logical applications to a business service.